[初級編] なぜ「AWS で負荷分散は３AZ にまたがるのがベストプラクティス」と言われるのか 可用性の面から考えてみた

みなさん、AWS使ってますか！（挨拶

AWSに限らず、ある程度の規模の何かしらの本番システムを組もうというときに、こういう言葉を聞いたことはないでしょうか。

「負荷分散装置の下に並べる分散先 (サーバ) は３台以上がよい」
「AWS であれば３アベイラビリティゾーン (AZ) にまたがるとよい」

負荷分散装置（ロードバランサー）は負荷を分散するのがお仕事です。分散するだけなら 2 台でもよさそうですよね？
AWS の３ AZ に至っては、そもそも AZ 単位の障害なんてそうそうないし、あったとしてももう片方の AZ が生きていればなんとかなりそうに思えます。

これがどういうことか、少し考えてみました。

おさらい：負荷分散装置と可用性の関係について

まずはおさらいです。

負荷分散装置（ロードバランサー）は単純化していえば、その名前の通りひとつの名前（FQDN）へのアクセスを複数のサーバに分散させることで、サーバ１台あたりの負荷を下げるためのものです。
1 台あたりの負荷がさがるということは、想定される最大負荷（仮に 100）に対して低い処理性能（例えば 60）しか持たないサーバを複数台（同 2 台）並べ分散させることで対応を可能にする（100 < 60x2）わけです。

この場合、仮に最大負荷が 1.5 倍（100 -> 150）になったとしても、台数だけを増やす（2 台 -> 3 台）ことで対応ができることになります（100x1.5 = 150 < 60x3 = 180）。
このことを、サーバ単体の性能を向上させるスケールアップ（Scale-Up）に対して、スケールアウト（Scale-Out）と呼びます。¹

ですがそのことに付随して別の機能も付加されるため、むしろそのことが目的として負荷分散装置を導入することもあります。

これは古くは DNS ラウンドロビンのようなテクニックで実現していた負荷分散が、専用のネットワーク機器として実装され、それが AWS などのクラウドインフラに乗るといった周辺環境とともに進化を遂げることで、きめ細かなコントロールが可能になったことによるものです。
代表的なものをいくつか列挙してみます：

• 変化する負荷に応じて動的に台数をコントロール（Auto Scale）し、余剰性能をなくしてコストを削減する
• 画像変換や暗号化処理など、各サーバで実行するには重い・重複する処理を負荷分散装置で肩代わり（オフロード）する
• 単純な分散ではなく、条件に応じて分散先やパラメータをコントロールする（画像などの静的コンテンツだけ専用サーバから送信させる、対外にだけメンテナンス画面を出す、特定の IP アドレスからのみアクセスを遮断したり、別のサーバへアクセスを向けるなど）
• 分散先（サーバ）を交換する際に、負荷分散先から外す・追加するなどのコントロールで、サービスに影響なく行うことを可能にする。メンテナンス性の向上
• 並列動作している分散先（サーバ）が 1 台故障しても、残りの台数で負荷を肩代わりしその間に復旧させる。全体として可用性 (Availability) を向上させる

つまり、負荷分散装置はサービスの可用性向上に一役買っているといえます。
そのことをおさえた上で、負荷「分散」について考えてみましょう。

２台で大丈夫？

最初に例をだした「最大 100 の負荷を、処理性能 60 のサーバ 2 台でさばく」で考えてみましょう。この状況でいえばなんの問題はありません。
各サーバには負荷 50 ずつしかこないため、60 の性能を持つサーバで対応するのは余裕です。

ここで、1 台が故障したことを考えます。

当然ですね。
これまで 2 台で支えていたところに、片方が倒れたらもう片方にはこれまでの 2 倍の負荷がかかることになります。キャパシティを超えた 40 分が処理されないだけならともかく、本来処理できるはずだった 60 のアクセスもサーバの高負荷によって処理がすすまず、いずれ生き残ったサーバも共倒れする運命にあります（合掌）。

これに対応するためには、各サーバが 100 の負荷に耐えられるように準備しておかなければなりませんが、、

それでは、最大 100 の負荷に対して処理性能 100 のサーバが 2 台必要になってしまいます。いくら可用性をあげるためとはいえ、想定最大負荷の 2 倍の能力を備えておく、あるいは普段は半分の性能しか使っていないというのは、ちょっと豪華すぎますね。

しかしながら「可用性 (Availability)」、つまり「そのサービスが動作し続けること」が主たる目的にあるのであれば、これ（余剰の性能を予備で持っておくこと）は許容しなくてはならないコストになります。しかしコストが高止まりしていては、そもそもそのサービスの継続がおぼつきません。

コストを下げるにはどうすればいいでしょうか。

３台であれば？ ４台・６台なら？

ではここで、3 台で分散させることを考えてみます。
１台故障した時には 100 ÷ 2 = 50 の負荷に耐えられればいいわけですから、平時には 50 x 3 = 150 の処理性能があることになります。最大負荷の 1.5 倍。言い換えると「通常運転時は確保された性能の 66.7%を使用」ということで、数値的にもまあまあではないでしょうか。

もっといえば、4 台であれば 1 台あたり処理性能 33.3。全体だと 1.3 倍で平常 75%という計算です。6 台なら 1 台あたり処理性能 20、全体で 1.2 倍・ 83%。
もちろんこれは単純計算でしかありませんが、分散先が増えれば増えるほど 1 台あたりに要求される能力が減り、確保しておかなければならない余剰性能が少なくてすむことがわかると思います。

もちろんサーバ１台あたりのコスト（価格・維持費）という面で考えると、性能とコストは比例しません。台数がふえればメンテナンスコストにも影響があります。全体的なバランスや、メンテナンスコストを下げるための別の施策（後述）とあわせて、このあたりは考える必要があるでしょう。

AZ x3 の重要性

ここまでは単純に、分散先サーバの話をしてきました。
一方で、AWS を使う上でアベイラビリティゾーン（Availability Zone、AZ ²）という考え方は重要です。

AWS では常日頃から「Everything fails all the time（すべてのものはいずれ壊れる）」という言い方をしており、Design for failure（障害発生を前提とした設計）が重要だと説いています。これは別に「AWS は故障しやすい」という意味ではなく ³、オンプレでは簡単ではなかった「複数のデータセンターでサービス展開」ということが、AWS というクラウドインフラであれば何の手間も追加コストもいらない、障壁がないのであればそれを利活用して SPOF（単一障害点）を排除しよう、という意図です。

(re:Invent 2019, Werner Vogels の基調講演より)

「じゃあふたつの AZ に分散すればよいのでは」

となるのですが、AZ 障害を考慮に入れるとそうともいえません。ちょうど 1 年前に東京リージョンでおきた事象をご記憶でしょうか。

トラフィックの分散という特性から、ELBの設定には最低でも2つのAZを指定しなくてはいけない。しかし、A氏の環境は2AZ構成だったことから、障害のあるELBを切り離そうとしてもできない状況だったという。

他メディアからの引用 で恐縮ですが、問題が起きた AZ を負荷分散装置（ELB）から切り離そうとした際に、ELB の仕様によりそれができなかったという例がありました。そもそも障害が発生している状態で構成変更を行うのも、得策かどうかとっさの判断がしかねます。そう考えると、普段から 3 AZ で稼働させておくことは重要といえます。

こちらについての詳細は、弊社 中山 の記事を参照ください。

もうひとつの理由として、先に説明した「分散先を 3 台以上に」という話もあります。2 AZ に 3 台となると、片方の AZ に 2 台を設置することになります。そちらの AZ で障害が発生した場合にのこり 1 台で全負荷を処理することになり、計算が狂います。
理想としては各 AZ で負荷が均等であることなので、3 AZ にそれぞれ 1 台ずつ、あるいは同数ずつを稼働させておく設計がよいでしょう。理想型としては、各 AZ ごとに 2 台ずつの 6 台体制でしょうか。

台数が増えることに対する課題と対処

話の成り行き上、2 台のサーバが 6 台に増えることになりました。とはいえそんなに簡単な話ではありません。

• 台数がふえることで構築や管理がたいへん
• ちょうどいい処理性能のサーバ = EC2 インスタンスタイプがない
• 台数増やせばコストが…

等々。
それらについてはここでは話しませんが、AWS においては、例えば以下のようなキーワードが問題解決につながると思います。

• AWS CloudFormation (CFn) や Terraform、AWS CDK といったプロビジョニング（構成管理）ツールの活用
• AutoScalingGroup
• RI、SP、Spot インスタンスの活用によるコスト削減
• AWS Systems Manager による構成管理・運用自動化、Amazon CloudWatch Dashboards による一元モニタリング
• 運用・監視 SaaS の導入
• サービスのコンテナ化・サーバーレス化、AWS Fargate
• マルチクラウドまで見据えた EKS の導入

すぐ使えるものもあればアーキテクチャから考え直さないとならないもの・体制強化まで必要なものまで、導入難易度も適用範囲も様々です。
これ以外にも、例えば AZ 間通信のレイテンシ問題や、単純に並列分散できない処理・ RDBMS など更新が必要なサービスの冗長化なども考慮事項にあがります。簡単ではありませんが解決策・緩和策はありますので、「どこまですべきか・するだけの価値があるか」を念頭に、ぜひ検討みてください。弊社もお手伝いします (ステマ)！

まとめ

ELB で負荷分散する場合、2 台じゃなくて 3 台以上、3 AZ に分散して導入するとよい、という話をしました。
途中でもふれたように、ここで紹介したものはあくまで単純計算の結果で、実際には個々のワークロードに応じて様々な事情を考慮しなくてはなりませんが、方向性として頭に入れておくとよいと思います。

AWS は普通に使っていると普通に使えてしまうので、平時ではついつい「1 台でいいか」「まあ 2 台あれば」と思いがちです。管理系や開発系のシステムであればそれでもいいのですが、サービス運用しているのであれば、可用性を伸ばすことに消極的になる理由はないはずです。
とはいえ、可用性は追求しだすと終わりがありません。手段が目的になるのは本末転倒です。SLA は当然のこと、SLI（サービスレベル指標）・ SLO（サービスレベル目標）を考えながら、システムの質向上のために何をどこまでやるのが最適か、繰り返しになってしまいますが、この機会にぜひ一度ご検討ください。

注釈